The X Window System is a network-transparent windowing system developed at the Massachusetts Institute of Technology. X systems provide support for window management operations, input and simple two-dimensional (2D) graphics operations. The X Window System, or X, has become a de facto industry standard in the raster-graphics workstation marketplace because it works well in the common computing environment comprising a network of dissimilar workstations. However, despite its popularity X still has some shortcomings. Its developers deliberately concentrated on solving the problems encountered in supporting windowing, input and simple 2D graphics output operations in the heterogeneous network environment, and deferred other difficult problems, such as providing direct support for three-dimensional (3D) graphics and image processing.
PEX is an extension to the core X Window System that provides 3D graphics support in an X environment. PEX is designed to efficiently support 3D graphics standards (PHIGS, GKS-3D, and the majority of the proposed PHIGS+ extension to PHIGS) in an X environment.
The X Window System is a client/server system, as shown in FIGS. 1(A) and 1(B). FIG. 1(A) schematically depicts a computer network comprising a first workstation running an application program (X client program) 10, a local area network (LAN) 12, a single process X Window display server with PEX extensions 14, and display hardware 16.
FIG. 1(B) schematically depicts an X/PEX system model comprising an application process, or client, 18, an X/PEX communication protocol 20, a network interface 22, an X server process 24 and a display hardware interface 26. The X server process 24 contains a core X server and any extensions. The X server process continuously runs on the display system; it is responsible for receiving and executing requests from all client processes and for reporting asynchronous events back to any interested clients. Clients can establish a connection and send requests to any device on the network that is executing an X server process. Communications between clients and servers are carried out using an existing interprocess communication protocol (e.g., TCP/IP, DECnet, or Unix sockets). The nature of the information passed between clients and servers is strictly defined by the X protocol specification and the protocol specifications for any extensions.
The strict definition of the X communication protocol provides network transparency. If all client and server processes strictly adhere to the protocol, a client process on one machine can send requests to a server process on any machine on the network, regardless of the CPU, operating system or architecture of either of the two machines. Similarly, a server process can execute requests issued by any client on the network, as long as the requests conform to the X protocol. This can make the fact that the two machines are connected via a network "transparent" to the user. Client applications can be written in such a way that they can access any X server on the network without being rewritten, recompiled or relinked.
FIG. 1(B) shows how data flows from the application down to the target display device. It is possible to build either PHIGS/PHIGS+ or GKS-3D programming interface libraries on top of PEX. An application can make calls to PHIGS/PHIGS+, GKS-3D, Xlib and X Toolkit libraries. These libraries in turn will format PEX and X protocol request packets and send them to the designated server process to be executed. The core X server receives and dispatches all incoming requests and hands PEX requests over to the PEX server extension to be processed. The X server and the PEX server extension can issue commands that cause primitives to be drawn on the display screen.
PEX operations obey the execution semantics defined by X. These state the following:
1. Each request is considered atomic (indivisible). PA1 2. There is no implied scheduling between requests received via separate connections. PA1 3. Requests received over a single connection are executed in the order they are received.
Most X server implementations are single-threaded and thus by definition follow the X execution semantics. However, such PEX operations as structure traversal and rendering may take considerable time to complete. This can lead to unacceptable behavior from a client's point of view. For example, a client that initiates a structure traversal can monopolize the server's ability to process requests, effectively preventing another client from doing simple text editing in another window. Multi-threaded servers may avoid this behavior by allowing other requests to be processed while lengthy operations are occurring. A connection will block if a request requires access to a resource that is already engaged in a lengthy operation. After the lengthy operation is completed the connection will unblock and the request will be processed. For instance, if a client initiates a structure traversal and then reads back the pixels using a core X request, the "read pixels" operation will not occur until the traversal has completed. On the other hand, an application performing lengthy rendering operations and a text-editing application may be supported simultaneously if they are operating in independent windows on the display.
The operation of a single process X/PEX display server will now be explained with reference to FIGS. 1(A), 2 and 3.
Requests for X and PEX services originating from the client program 10 are transmitted across the local area network 12 and arrive at the server 14. The requests, after being processed by the server, may result in modification of server data structures, generation of responses to the client program or changes to the appearance of the image on the display hardware screen.
FIG. 2 schematically depicts a system for dispatching X Window requests. The system comprises a request dispatcher 28 and a set of dispatch tables 30, e.g., one table for each client connection. (Note that the X server is structured such that there can be a unique dispatch table for each client, however in most server implementations there is actually a single dispatch table that is shared by all clients). Each table 30 comprises a first part 32 containing a list of addresses of core X request servicing functions 36 and a second part 34 containing a list of addresses of extension request servicing functions 38, 40, 42. In the exemplary system of FIG. 2, function 42 corresponds to a PEX extension request.
The dispatcher 28 sits idle, waiting for a client request to arrive, when the server is not occupied with a request. When a request arrives, the client that originated the request is identified and the specific protocol service requested is determined. The identity of the client is used to address the client's dispatch table from the set of tables 30. Once the request is identified and the address of the request servicing function is determined, that function is called and it performs operations required to service the request. An error response message will be sent to the client that originated the request if an error is encountered while executing a request servicing function. When the request servicing function is finished executing, control is returned to the request dispatcher 28 to await the next client request. Note that the display server has a single thread of execution; once the request servicing function is called, its execution continues to completion. Any messages sent back to the client, whether in response to a request or due to an error, are completed before returning to the request dispatcher 28.
FIG. 3 schematically depicts a system for dispatching PEX requests. This system includes a PEX request dispatcher 50 and a single table 52 of addresses of PEX request servicing functions 54. The server's single thread of execution is directed to the PEX request dispatcher 50 whenever a client requests any type of PEX extension operation, thereby invoking the PEX request servicing function 42 (FIG. 2). The PEX request servicing function 42 is invoked as a result of the request dispatcher 28 recognizing the PEX extension request and calling the PEX extension function 42.
The system of FIG. 3 further refines the client's request to determine the particular PEX function that is needed. A process similar to the one described above for X request dispatching takes place at this level. The PEX request servicing functions 54, like the X request servicing functions 36 (FIG. 2), execute in a single thread until completion, and then return control to the request dispatcher 28. The PEX functions may also send messages back to the client.
A major shortcoming of prior art systems of the type described above is that in such systems servicing of core X and PEX requests is handled by a single software process executing on the computer acting as the display server. Request servicing functions are scheduled (dispatched) in the order in which the corresponding requests arrive, with each request commanding the full attention of the display server process until the request has been fully serviced. This regime diminishes the interactivity of the system because PEX requests typically require substantially more time to service than core X requests.